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Label Edge Router Forwarding of IPv4 Option Packets 
Abstract 


This document specifies how Label Edge Routers (LERs) should behave 
when determining whether to MPLS encapsulate an IPv4 packet with 
header options. Lack of a formal standard has resulted in different 
LER forwarding behaviors for IPv4 packets with header options despite 
being associated with a prefix-based Forwarding Equivalence Class 
(FEC). IPv4 option packets that belong to a prefix-based FEC, yet 
are forwarded into an IPv4/MPLS network without being MPLS- 
encapsulated, present a security risk against the MPLS 
infrastructure. Further, LERs that are unable to MPLS encapsulate 
IPv4 packets with header options cannot operate in certain MPLS 
environments. While this newly defined LER behavior is mandatory to 
implement, it is optional to invoke. 


Status of This Memo 
This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 
Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6178. 
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Copyright Notice 


Copyright (c) 2011 IETF Trust and the persons identified as the 
document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
described in the Simplified BSD License. 
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1. Motivation 


This document is motivated by the need to formalize MPLS 
encapsulation processing of IPv4 packets with header options in order 
to mitigate the existing risks of IPv4 options-—based security attacks 
against MPLS infrastructures. We believe that this document adds 
details that have not been fully addressed in [RFC3031] and 
[RFC3032], and that the methods presented in this document update 
[RFC3031] as well as complement [RFC3270], [RFC3443], and [RFC4950]. 


2. Introduction 


The IPv4 packet header provides for various IPv4 options as 
originally specified in [RFC791]. IPwv4 header options are used to 
enable control functions within the IPv4 data forwarding plane that 
are required in some specific situations but not necessary for most 
common IPv4 communications. Typical IPv4 header options include 
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provisions for timestamps, security, and special routing. Example 
IPv4 header options and applications include but are not limited to 
the following: 


o Strict and Loose Source Route Options: Used to IPv4 route the 
IPv4 packet based on information supplied by the source. 


o Record Route Option: Used to trace the route an IPv4 packet 
takes. 


o Router Alert Option: Indicates to downstream IPv4 routers to 
examine these IPv4 packets more closely. 


The list of current IPv4 header options can be accessed at [IANA]. 


IPv4 packets may or may not use IPv4 header options (they are 
optional), but IPv4 header option handling mechanisms must be 
implemented by all IPv4 protocol stacks (hosts and routers). Each 
IPv4 header option has distinct header fields and lengths. IPv4 
options extend the IPv4 packet header length beyond the minimum of 20 
octets. As a result, IPv4 packets received with header options are 
typically handled as exceptions and in a less efficient manner due to 
their variable length and complex processing requirements. For 
example, many router implementations punt such IPv4 option packets 
from the hardware forwarding (fast) path into the software forwarding 
(slow) path causing high CPU utilization. Even when the forwarding 
plane can parse a variable-length header, it may still need to punt 
to the control plane because the forwarding plane may not have the 
clock cycles or intelligence required to process the header option. 


Multi-Protocol Label Switching (MPLS) [RFC3031] is a technology in 
which packets associated with a prefix-based Forwarding Equivalence 
Class (FEC) are encapsulated with a label stack and then switched 
along a label switched path (LSP) by a sequence of label switch 
routers (LSRs). These intermediate LSRs do not generally perform any 
processing of the IPv4 header as packets are forwarded. (There are 
some exceptions to this rule, such as ICMP processing and LSP ping, 


as described in [RFC3032] and [RFC4379], respectively.) Many MPLS 
deployments rely on LSRs to provide layer 3 transparency much like 
ATM switches are transparent at layer 2. Such deployments often 


minimize the IPv4 routing information (e.g., no BGP transit routes) 
carried by LSRs since it is not necessary for MPLS forwarding of 
transit packets. 


Even though MPLS encapsulation seems to offer a viable solution to 
provide layer 3 transparency, there is currently no formal standard 
for MPLS encapsulation of IPv4 packets with header options that 
belong to a prefix-based FEC. Lack of a formal standard has resulted 
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in inconsistent forwarding behaviors by ingress Label Edge Routers 
(LERs). When IPv4 packets are MPLS encapsulated by an ingress LER, 
for example, the IPv4 header including option fields of transit 
packets are not acted upon by downstream LSRs that forward based on 
the MPLS label(s). Conversely, when a packet is IPv4 forwarded by an 
ingress LER two undesirable behaviors can result. First, a 
downstream LSR may not have sufficient IPv4 routing information to 
forward the packet resulting in packet loss. Second, downstream LSRs 
must apply IPv4 forwarding rules that may expose them to IPv4 
security attacks. 


IPv4 option packets that belong to a prefix-based FEC, yet are 
forwarded into an IPv4/MPLS network without being MPLS-encapsulated, 
present a security risk against the MPLS infrastructure. Further, 
LERs that are unable to MPLS encapsulate IPv4 packets with header 
options cannot operate as an LER in certain MPLS environments. This 
new requirement will reduce the risk of IPv4 options-based security 
attacks against LSRs as well as assist LER operation across MPLS 
networks that minimize the IPv4 routing information (e.g., no BGP 
transit routes) carried by LSRs. 


3. Specification of Requirements 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 


document are to be interpreted as described in [RFC2119]. 


4. Ingress Label Edge Router Requirement 


An ingress LER MUST implement the following policy: 


o When determining whether to push an MPLS label stack onto an 
IPv4 packet, the determination is made without considering any 
IPv4 options that may be carried in the IPv4 packet header. 
Further, the label values that appear in the label stack are 
determined without considering any such IPv4 options. 


This policy MAY be configurable on an ingress LER, however, it SHOULD 
be enabled by default. When processing of signaling messages or data 
packets with more specific forwarding rules is enabled, this policy 
SHOULD NOT alter the specific processing rules. This applies to, but 
is not limited to, Resource Reservation Protocol (RSVP) as per 
[RFC2205], source routing as per [RFC791], as well as other FEC 
elements defined by future specifications. Further, how an ingress 
LER processes the IPv4 header options of packets before MPLS 
encapsulation is out of scope since these are processed before they 
enter the MPLS domain. 
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Implementation of the above policy prevents IPv4 packets that belong 
to a prefix-based FEC from bypassing MPLS encapsulation due to header 
options. The policy also prevents specific option types such as 
Router Alert (option value 148) from forcing MPLS imposition of the 
MPLS Router Alert Label (label value 1) at ingress LERs. Without 
this policy, the MPLS infrastructure is exposed to security attacks 
using legitimate IPv4 packets crafted with header options. Further, 
LERs that are unable to MPLS encapsulate IPv4 packets with header 
options cannot operate as an LER in certain MPLS environments as 
described in Section 2. 


5. Security Considerations 


There are two potential categories of attacks using crafted IPv4 
option packets that threaten existing MPLS infrastructures. Both are 
described below. To mitigate the risk of these specific attacks, the 
ingress LER policy specified above is required. 


5.1. IPv4 Option Packets That Bypass MPLS Encapsulation 


Given that a router’s exception handling process (i.e., CPU, 
processor line-card bandwidth, etc.) used for IPv4 header option 
processing is often shared with IPv4 control and management protocol 
router resources, a flood of IPv4 packets with header options may 
adversely affect a router’s control and management protocols, 
thereby, triggering a denial-of-service (DoS) condition. Note, IPv4 
packets with header options may be valid transit IPv4 packets with 
legitimate sources and destinations. Hence, a DoS-like condition may 
be triggered on downstream transit IPv4 routers that lack protection 
mechanisms even in the case of legitimate IPv4 option packets. 


IPv4 option packets that belong to a prefix—-based FEC yet bypass MPLS 
encapsulation at an ingress LER may be inadvertently IPv4 routed 
downstream across the MPLS core network (not label switched). This 
allows an external attacker the opportunity to maliciously craft 
seemingly legitimate IPv4 packets with specific IPv4 header options 
in order to intentionally bypass MPLS encapsulation at the MPLS edge 
(i.e., ingress LER) and trigger a DoS condition on downstream LSRs. 
Some of the specific types of IPv4 option-based security attacks that 
may be leveraged against MPLS networks include the following: 


o Crafted IPv4 option packets that belong to a prefix—-based FEC 
yet bypass MPLS encapsulation at an ingress LER may allow an 
attacker to DoS downstream LSRs by saturating their software 
forwarding paths. By targeting a LSR’s exception path, control 
and management protocols may be adversely affected and, thereby, 
an LSR’s availability. This assumes, of course, that downstream 
LSRs lack protection mechanisms. 
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o Crafted IPv4 option packets that belong to a prefix-based FEC 
yet bypass MPLS encapsulation at an ingress LER may allow for 
IPv4 Time to Live (TTL) expiry-based DoS attacks against 
downstream LSRs. MPLS enables IPv4 core hiding whereby transit 
IPv4 traffic flows see the MPLS network as a single router hop 
[RFC3443]. However, MPLS core hiding does not apply to packets 
that bypass MPLS encapsulation and, therefore, IPv4 option 
packets may be crafted to expire on downstream LSRs which may 
trigger a DoS condition. Bypassing MPLS core hiding is an 
additional security consideration since it exposes the network 
topology. 


o Crafted IPv4 option packets that belong to a prefix-based FEC 
yet bypass MPLS encapsulation at an ingress LER may allow for 
DoS attacks against downstream LSRs that do not carry the IPv4 
routing information required to forward transit IPv4 traffic. 
Lack of such IPv4 routing information may prevent legitimate 
IPv4 option packets from transiting the MPLS network and, 
further, may trigger generation of ICMP destination unreachable 
messages, which could lead to a DoS condition. This assumes, of 
course, that downstream LSRs lack protection mechanisms and do 
not carry the IPv4 routing information required to forward 
transit traffic. 


o Crafted IPv4 option packets that belong to a prefix-—based FEC 
yet bypass MPLS encapsulation at an ingress LER may allow an 
attacker to bypass LSP Diffserv tunnels [RFC3270] and any 
associated MPLS Class of Service (CoS) field [RFC5462] marking 
policies at ingress LERs and, thereby, adversely affect (i.e., 
DoS) high-priority traffic classes within the MPLS core. 
Further, this could also lead to theft of high-priority services 
by unauthorized parties. This assumes, of course, that the 
[RFC3270] Pipe model is deployed within the MPLS core. 


o Crafted RSVP packets that belong to a prefix-based FEC yet 
bypass MPLS encapsulation at an ingress LER may allow an 
attacker to build RSVP soft-states [RFC2205] [RFC3209] on 
downstream LSRs which could lead to theft of service by 
unauthorized parties or to a DoS condition caused by locking up 
LSR resources. This assumes, of course, that the MPLS network 
is enabled to process RSVP packets. 


The security attacks outlined above specifically apply to IPv4 option 
packets that belong to a prefix-—based FEC yet bypass ingress LER 
label stack imposition. Additionally, these attacks only apply to 
IPv4 option packets forwarded using the global routing table (i.e., 
IPv4 address family) of a ingress LER. IPv4 option packets 
associated with a BGP/MPLS IPv4 VPN service are always MPLS 
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encapsulated by the ingress LER per [RFC4364] given that packet 
forwarding uses a Virtual Forwarding/Routing (VRF) instance. 
Therefore, BGP/MPLS IPv4 VPN services are not subject to the threats 
outlined above [RFC4381]. Further, IPv6 [RFC2460] makes use of 
extension headers not header options and is therefore outside the 
scope of this document. A separate security threat that does apply 
to both BGP/MPLS IPv4 VPNs and the IPv4 address family makes use of 
the Router Alert Label. This is described directly below. 


5.2. Router Alert Label Imposition 


[RFC3032] defines a Router Alert Label (label value of 1), which is 
analogous to the Router Alert IPv4 header option (option value of 
148). The MPLS Router Alert Label (when exposed and processed only) 
indicates to downstream LSRs to examine these MPLS packets more 
closely. MPLS packets with the MPLS Router Alert Label are also 
handled as an exception by LSRs and, again, in a less efficient 
manner. At the time of this writing, the only legitimate use of the 


Router Alert Label is for LSP ping/trace [RFC4379]. Since there is 
also no formal standard for Router Alert Label imposition at ingress 
LERS: 


o Crafted IPv4 packets with specific IPv4 header options (e.g., 
Router Alert) and that belong to a prefix-based FEC may allow an 
attacker to force MPLS imposition of the Router Alert Label at 
ingress LERs and, thereby, trigger a DoS condition on downstream 
LSRs. This assumes, of course, that downstream LSRs lack 
protection mechanisms. 
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